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Inference and Cover Stories 
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A common use for cover stories is to provide a plausible explanation for an otherwise 
sensitive event . For example, a plane might be said to carry food when its actual cargo is 
weapons . Without a cover story, the fact that the cargo is not identified may lead to 
increased interest from an uncleared user, something which may not be desirable if a 
mission is to be success ful. 

Cover stories may also be used to release shades of information . Here, instead of lying 
they are releasing only sanitized information. At the confidential level , a user may be told 
that a plane is carrying equipment, while a top secret user is told that the plane is carrying 
electronic equipment. 

Cover stories may not always have the ability to protect sensitive information . For 
example, an uncleared user may have enough world knowledge to discover that a given cover 
story is not plausible. There is a difference J however, between a cover story that cannot 
protect sensitive information and a cover story, which itself causes a breach of security. This 
paper examines cover stories that indirectly disclose the very information they are 
attempting to protect. 

j 

INTRODUCTION 

j 

Cover stories are plausible explanations which replace gaps of information that the 
low user (one who is uncleared or insufficiently cleared for the information) would 
normally see, gaps that might otherwise cause a curious. user to attempt to piece together 
information for which he is unauthorized. Ajprimary goal of a cover story is to satisfy the 
curiosity of an unauthorized user. 

In virtually every plausible cover story' however, is some factual information. For 
example, if Smith is a radar technician and that information is secret, then a plausible 
cover for Smith would not be "Jones is an engineer.” Generally speaking, the object for 
which a cover story is being developed must be correctly identified . 1 



1 . Where the object is not correctly identified, as in someone going "under cover,** some attributed) of that 
object must be acknowledged (i.e., height, weight, etc.) 
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In addition to identifying the object, plausibility often requires other information 
about the object to be identified. "Ensurinfptfcat the factual information released is 
unclassified 2 is not sufficient, because an attacker can now use this factual information to 
derive new and possibly classified information on the object via inference. To be sure the 
cover story does not breach security, it must be shown that all factual information released 
in the cover story and all inferences possible from that factual information are 
unclassified. 

This paper focuses on 

• Cover stories, 

• How an improper cover story can lead to a breach of security, and 

• Recognizing potential inferences caused by cover stories. 



COVER STORIES THAT CAN’T PROTECT INFORMATION 

Cover stories are used to protect information. Typically, they give a plausible 
explanation for information that would not otherwise exist at a user's security level. 
However, a user may have enough data to piece together what the cover story is trying to 
protect. When this happens, the cover story cannot be relied on for protection, although it 
may be enough of a deterrent to mislead a portion of the unauthorized users. 

In the Mission table (M) shown below, the cover story for flight# Cl A2946 is that it is 
a supply mission, running medical supplies to Europe. 
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Fig.l. 

This may appear sufficient to convince the novice user that flight# C1A2946 is a supply 
mission. Figure 2, however, shows that an unclassified user can piece together the fact 
that flight# C1A2946 is a reconnaissance mission. If this relationship is secret, then the 



2 . or properly classified 



UNCLASSIFIED 



174 






DOCID: 3928677 



INFERENCE AND COVERSTORIES UNCLASSIFIED 

cover story in figure 1 alone cannotWotect that relationship. This is an example of a cover 
story that simply cannot protect -information (because the information is available 
elsewhere). For this particular example, a second cover story 3 in either FP, P, or OM is one 
alternative solution to protecting nbhe secret relationship; a second alternative is to 
consider redesigning or reclassifying the schema to avoid this type of information flow. 
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Fig. 2. 



COVER STORIES THAT BREACH SYSTEM SECURITY 

In cover stories where some factual data are released, there exists the possibility that a 
low user could exploit these data to infer high (i.e., highly classified information or that 
which a "low" user cannot have access to) information. The Organization (0) table shown 
in figure 3 contains the relationship between org "XYZ” and specialty "Russian 
Language” at the confidential level. At the unclassified level, XYZ's cover story is that its 
specialty is simply "Language.” This cover story is consistent with the user's classification 
guideline listed in appendix A. In this case, the actual phone number for XYZ was 
released. Although this is not in direct violation of the classification guideline, it is an 
indirect breach of security. In conjunction with the database schema shown in figure 4, a 
low user can use XYZ’s phone number to infer its specialty by identifying potential 
employees of XYZ and their specialty. 

This is an example of a cover story which itself causes a breach of security, by 
releasing information necessary to complete an inference path./ 



3. The original data would have to be removed or reclassified. 
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Fig. 3. 



PLAUSIBILITY AND USABILITY 

Why release factual information in a cover story? It is required in some circumstances 
to make the cover story plausible. An incorrect attribute may lead a user to question the 
validity of other attributes in the record, thereby defeating the purpose of the cover story. 
Unsatisfied with the information, the user may try to retrieve a different answer using an 
alternative method (i.e., inference). Where the cover story is really a sanitized version of 
the truth (fig. 3), factual information is sometimes required to make the cover story usable. 

Although it is always possible to force the user to redesign the database to reduce or 
possibly eliminate poor schema design, it is our goal to allow these designs as long as their 
inefficiency does not have an adverse effect on security. Forcing users to adhere to strict 
design principles can have the effect of driving them away from secure systems altogether. 
The goal here is to impact the users only when Security is at risk, allowing them to work 
without restriction where possible. The user is responsible for proper classification of data 
within a record, while the database monitors classification consistency among collections 
of tables. 

As stated earlier, virtually every cover story contains factual information. What must 
be ensured is that this information cannot directly or indirectly disclose sensitive data to 
an unauthorized user. 
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RECOGNIZING INFERENCES CAUSED BY COVER STORIES 

The design flaw whereby a cover story opens an inference channel was first introduced 
in [1]. The channel can be characterized by a relation whose attribute leads to an external 
attribute which coexists (and is classified) in the original relation. The definition uses the 
notion of a path and level of a path. These are discussed here and are used in the formal 
definition that follows. 

A path identifies the set of attributes and relations used to substantiate a relationship 
between two attributes; it is a road map showing how the attributes are joined. The 
smallest path is between two attributes in the same relation, and by definition it has a 
length of one. The Organization (O) table in figure 4 shows the relationship between org 
and phone. It has a length of one, and the Ipath is written org (0) phone . More complex 
relationships use a recursive definition for path. Each join increases the length by one. 
The relationship between org and employee in figure 4 is substantiated by joining the 
Organization and Phonebook relations. The path has a length of two and is written org (O) 
phone (OxP) employee. Cyclical paths are not allowed; neither tables nor attributes can be 
revisited in a path. 

Given that; 

A is a set of n + 1 attributes, and 

R is a set of n relations 
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A path of length (n= 1) is defined as: 

P(ao,ai ,ri,A,R) = [ao (ri) aj | 
ao,ai £ A 
A ao * ai 
An€R 
Aao.ai € ri 
A Cardinality (A) = 2 
A Cardinality (R) = 1] 

A path of length (n > 1) is defined as: 

P(ao»An»rn»A,R) = [P(ao,a n -i,r n -i,A-an,R-rn) (r n -i x r n ) a„ | 

80 i®n-l>®n ^ A 

A a© * a n .i * a„ 

Ar n . lf r n €R 
A r n .! at r n 
Aa n .i,a n £ r n 
Aa n .|(r„.|] 

The level of a path is defined by the relations used in traversal; it is composed of the 
path’s hierarchical and nonhierarchical security levels unioned together. The hierarchical 
level is the least upper bound of all the hierarchical levels encountered in the path. The 
nonhierarchical level is the union of all nonhierarchical levels encountered. 

The level of a path P at time t is defined as: 

L(p,t) = [L h (R,t) U L c (R,t) 1 3 ao,a n ,r n ,A [p= P(ao,a n ,r n ,A,R) A t € time]] 

Where 

L h (nil,t) = U 

Lh(R,t)=[Level(r,t) | r € R A Level (r,t) a Lh (R-r,t)] 

Lc(nil f t)=nil , 

Lc(R,t) = [Cbmp(r,t) U L c (R-r,t) | r € R] 

Level(r,t) = Hierarchical security level associated with relation r at time t 
Comp(r,t) = Nonhierarchical compartments) associated with relation r at time t 

A = set of attributes 
R = set of relations 

{U, C, S, TS} = Hierarchical security levels, and U < C < S < TS 
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We say that a coyer story is the cause of inference if it releases information that could 
be used to yield the true state of what the cover story is designed to protect. Formally 
stated, potential inference through the use of a cover story is defined as 4 

I c (aj,aj) = [TRUE | 3 Pi ,P2, a k> r if m Ai , A 2 ,Ri ,R 2 >t 
[pi = ai(r)aj = P(ai,aj,r,Ai,Ri) 

Ap2=P(ai,aj,r n ^ 2 .R2) 

A Bj ^ Bj ^ aj( 

A ai (r) ak € P 2 
A ->(L(p lf t)S L(p 2 ,t))]] 

Looking back at our example in figure 4, we see that specialty (ap is the attribute that 
is both external and local to Organization. Phone (ak) is the attribute or "hook” that can be 
used in a path leading to specialty outside of Organization. Using our definition, we see 
that a potential inference does exist.. The values used to substantiate this are shown 
below. 

ai=org, aj= specialty, ajt= phone 

Ai = {org, specialty} 

A2 = {org, phone, emp, specialty} 
r=0 



I Ri = {0} 

i R 2 ={0,E,P} 

i pi = org (O) specialty 

I . p2 = org (0) phone (OxE) emp (ExP) specialty 

I 

• org (O) phone € P2 

i -(L( P1 = C)^L(P2=U)) 

{ .-. l c (org, specialty) = TRUE 

V 

ij Notice that we assign path classifications to suit our needs. The only constraint is that 

| the levels assigned are consistent with the range of possible values. For example, 

] Organization can be assigned either unclassified (U) or confidential (C) security levels; 

l however, Phonebook is strictly unclassified. The fact that there exists a potentially 

classified path pi and a potentially unclassified path P2 is a necessary ingredient to show 
the design is inherently flawed and could potentially breed inference. 

5 The actual tuple values shown in figure 4 are not used when determining the 

l soundness of the design. They are used here to illustrate how a poor design could lead to 

an inference path, via specific database instance. 



4. In this context, 6 is used to denote a subpath,, i.e., org (0) phone € org (0) phone (OxE) emp (ExP) specialty. 
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A database is said to be free of potential inference through the abuse of a cover story if 
for all attributes a* and aj, I c (&i,&j) is false. 

Where it is unfeasible to eliminate potential inference paths, run-time analysis would 
monitor the contents of the database based on design-time analysis. Run-time analysis 
would substantiate when a potential inference path becomes an actual inference path. 



RELATIONSHIP TO OTHER CLASSES OF INFERENCE 

A database where IcCa^ap is false for all a, and aj is by no means inference free; it 
means only that a cover story cannot be used against itself \ The database is still subject to 
other classes of inference; there is no guarantee that the information released in a cover 
story could not be used to exploit some other type of inference channel, hence the need for 
additional analysis. The inference definition presented here identifies a specific class of 
inference. It depends on a set of complementary tools which detect other classes of 
inference in order to form a comprehensive inference policy. Such a policy is required if we 
are to trust multilevel databases to truly protect the information it manages. 



SUMMARY 

Cover stories, whose intention is to protect information, can fail in two ways. They can 
take either an active or a passive role in the disclosure of information to the unauthorized 
user. 

Garvey [4] recognized that a cover story cannot protect information if the user has 
enough data to piece together via inference the information the story is trying to protect. 
In this case, the cover story is taking a passive role in the disclosure of information to the 
unauthorized user. To counter this he indicates the need to identify such situations and 
provide additional cover stories to block the inference path(s) which jeopardize the initial 
cover story. 

Plausibility of a cover story may require some factual, noncritical information to be 
released. Where factual information is released, a hostile user could possibly abuse the 
information to obtain critical (high) data by using them to complete an inference path. 
Here, the cover story is taking an active role in the disclosure of information to an 
unauthorized user. This paper has focused on detecting whether a cover story can be used 
to disclose information itself is trying to protect. This paper has not addressed the impact 
a cover story has on other information in the database which the cover story does not 
directly protect; i.e. ( this paper has not discussed the impact a cover story has on other 
classes of inference. Such considerations are being addressed separately, with the long- 
term goal of developing a policy that does address a range of inference classes. 

Finally, the definition of I^a^ap would presumably check the entire database to 
determine if a cover story could exist and could potentially be used to divulge the 
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relationship between ai and aj. Alternatively, one could modify the definition to use it as a 
specific tool in developing cover stories. Passing r as an argument, rather than testing to 
see if there exists some r that would satisfy the equation, would provide a useful tool to 
someone creating a cover story in a specific relation. Additionally, instead of returning 
TRUE, the definition would return the offending piece of information: 

Ic(ai,aj,r) = [aj 3 pi,p2,r„,Ai ,A 2 ,Ri,R2,t 
[pl = a;(r)aj = P(ai,aj,r,Ai ,Rj) 

A p2 = P(ai,aj,r n ,A2,R2> 

A ai * aj at 
Aai(r)ajc€p2 
A -v(L(pi,t) S L(p 2 ,t))]] 

Applying this to the cover story we wish to pose for specialty in the Organization 
relation of figure 4: 

lc(org, specialty, 0) = phone 

This indicates that if the actual phone number is supplied in a cover story for 
Organization, it is possible a hostile user could complete an inference path between org 
and specialty using phone ; to prevent this, a cover story for phone number must be 
provided. 
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Appendix A 

Mock Classification Guideline 

® An organization’s name alone is not classified. 

• An organization’s specialty is not classified unless stated otherwise. 

• The relationship between organization and specialty is confidential if its specialty is 
one of the following: 

• Russian Language 
o Metalinguistics 

• Optical Fiber Transmission 

• Civil Engineering 

If the specialty falls within these classified areas, the following unclassified specialties 
are to be used when referencing that organization to an unclassified user: 

Classified Specialty Unclassified Specialty Description 

Russian Language Language 

Metalinguistics 

Optical Fiber Transmission Engineering 

Civil Engineering 

• To provide consistency for the unclassified user, any record which relates organization 
and specialty at the confidential level must be polyinstantiated at the unclassified 
level. The record at the unclassified level will reflect the organization’s unclassified 
specialty. 
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